feat(accounts): add the ISV payout schedule fields and funds_transfer_type on payouts - #653

…_type on payouts

From the 2026-08-05 spec. Verified against it with the RAG rather than the ticket
text, which turned out to overstate the work.

The ISV part is not five new schemas. The payout schedule endpoint gained an anyOf
with a SaaS seller variant, and what that variant actually adds on the wire is two
fields: balance_minimum, the amount to retain in the sub-entity's available balance,
and carry_forward_enabled, whether a balance below the minimum rolls into the next
payout. Both go on the request and the response.

The ScheduleFrequency*Isv schemas serialise identically to the ones already here:
same by_day array, same by_month_day array. Only the accepted values differ, and
the API enforces them. Adding parallel classes with identical wire shapes would have
doubled the public surface for nothing, so the constraints are documented on the
existing classes instead: working days only for ISV weekly and daily, and only
[1], [15], [1,15] or [1,16] for ISV monthly.

The card payout side is one field, and the ticket points at the wrong half:
funds_transfer_type already existed on the payout REQUEST via PaymentInstruction.
What was missing is the response, where PaymentInstructionResponse carried only
value_date.

Two of the four tests cover absence rather than presence. A standard schedule must
not emit balance_minimum or carry_forward_enabled at all, since either leaking in as
a null or a zero would make the API read it as an ISV schedule, and both must come
back null rather than 0/false so a caller can tell "not applicable" from "set to
zero".

Blocks C and D of the ticket need no work in Java: the hosted payment and payment
link responses extend Resource, which already maps _links, and
PaymentInstrumentRequest already has label, currency and instrumentDetails.

Refs INT-1684.